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EXECUTIVE  SUMMARY 


This  report  presents  the  results  of  the  first  of  a  series  of  studies  being  conducted 
by  ACT-350  at  the  Federal  Aviation  Administration  (FAA)  William  J.  Hughes 
Technical  Center  to  evaluate  and  refine  the  controller  human  computer  interface 
(HCI),  air  traffic  procedures,  and  training  for  Controller-Pilot  Data  Link 
Communications  (CPDLC).  The  objectives  of  this  study  were  to:  (1)  evaluate  the 
baseline  Display  System  Replacement  (DSR)  HCI  and  functionality  for  the  four 
CPDLC  Build  I  (CPDLC  I)  services;  (2)  assess  initial  concepts  for  implementing 
the  route  assignment  and  downlink  services  needed  for  CPDLC  Build  IA  (CPDLC 
IA);  and  (3)  examine  alternatives  for  Full  Data  Block  (FDB)  Data  Link  symbols 
available  in  DSR. 

Eight  en  route  Air  Traffic  Control  Specialists  (ATCS)  participated  in  the  study. 
The  controllers  received  classroom  training  and  hands-on  practice  with  the  DSR 
and  the  CPDLC  HCI  in  the  high-fidelity  air  traffic  control  (ATC)  simulation 
laboratory  at  the  Technical  Center.  Following  4  hours  of  dynamic  simulation 
experience  with  CPDLC  I,  the  controllers  completed  individual  design  reviews, 
and  participated  in  a  group  debriefing  on  the  HCI  and  functionality  provided  by 
the  baseline  CPDLC  I  services.  Finally,  the  controllers  were  exposed  to  baseline 
designs  for  the  downlink  and  route  assignment  services,  exercised  the  services  in 
the  laboratory,  and  made  recommendations  for  design  changes  in  a  group 
debriefing. 

The  group’s  design  recommendations  were  divided  into  two  categories.  The  first 
category  included  design  changes  that  were  judged  as  essential  to  the  successful 
deployment  of  CPDLC  I  during  the  limited  key  site  implementation.  The  second 
included  modifications  and  enhancements  that  will  be  mandatory  for  inclusion  in 
CPDLC  IA  and  future  system  builds. 

The  following  were  design  improvements  considered  essential  for  CPDLC  I: 

a.  Status  list  message  entries  that  are  in  a  non-normal  state  (e.g.,  FAI, 
UNA,  TIM)  must  be  visually  emphasized  to  improve  the  alerting  value  of  the 
state  indicators. 

b.  The  Data  Link  eligibility  symbol  in  the  FDB  should  be  changed  to  a 
filled  diamond,  and  the  symbol  used  to  indicate  an  ongoing  transfer  of 
communication  should  be  changed  to  a  lightning  bolt. 

c.  The  Data  Link  Settings  HCI  should  be  modified  to  permit  more  efficient 
and  accurate  controller  interaction. 
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d.  The  locations  of  two  Data  Link  keyboard  keys  should  be  changed  to 
improve  accessibility. 

Additional  design  changes  strongly  recommended  for  future  system  builds 
included  converting  Data  Link  lists  to  DSR  views  and  providing  improved 
functionality  and  a  dedicated  HCI  to  the  Radar  Associate  Controller  (D-Side) . 
Specific  suggestions  for  implementing  the  recommended  modifications  to 
CPDLC  I,  and  future  system  builds  are  presented  in  the  results  section  of  this 
report. 

The  design  generation  exercise  for  the  CPDLC  IA  route  assignment  service  and 
for  displaying  and  processing  downlinked  altitude  requests  yielded  a  number  of 
recommended  modifications  to  the  baseline  designs.  These  changes  will  be 
incorporated  into  the  Data  Link  test  bed  and  evaluated  in  future  simulation 
studies. 
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1.  INTRODUCTION. 


1.1  PURPOSE. 

This  document  describes  the  findings  of  the  first  of  a  series  of  studies  that  will  be 
conducted  by  ACT-350  at  the  Federal  Aviation  Administration  (FAA)  William  J. 
Hughes  Technical  Center  to  evaluate  and  refine  the  controller  human  computer 
interface  (HCI),  air  traffic  procedures  and  training  for  the  first  build  of 
Controller-Pilot  Data  Link  Communications  (CPDLC).  The  study  described  here 
is  in  accordance  with  the  recommendations  and  goals  presented  in  the  CPDLC 
Roadmap  for  Human  Factors  Activities  (Data  Link  Human  Factors  Working 
Group,  1998). 

1.2  CPDLC  IMPLEMENTATION  PLANS. 

In  cooperation  with  industry,  the  FAA  has  adopted  a  revised  plan  for 
implementing  CPDLC  in  en  route  airspace.'  The  new  implementation  path 
bypasses  the  original  plan  to  conduct  an  early  operational  trial  of  CPDLC  using 
the  ARINC  Communications  Addressing  and  Reporting  System  (ACARS) 
subnetwork.  Instead,  development  and  testing  will  be  focused  on  an 
Aeronautical  Telecommunications  Network  (ATN)-  compliant  implementation 
using  the  VDL  Mode  2  subnetwork  which  will  be  capable  of  effectively 
supporting  a  broad  range  of  air  traffic  control  (ATC)  communications  services. 

The  FAA’s  goal  is  to  field  a  full  CPDLC  application  by  2005.  This  will  be 
accomplished  under  a  phased  approach.  The  initial  phase  (CPDLC  I)  will 
introduce  the  messages  required  to  provide  four  non-time-critical  services: 
Transfer  of  Communication  (TC),  Initial  Contact  (IC),  Altimeter  Setting  (AS), 
and  a  free  text  menu  capability  (MT)  used  to  send  informational  messages  to  the 
flight  deck.  CPDLC  I  will  be  fielded  at  a  key  site  (Miami  Air  Route  Traffic 
Control  Center  (ARTCC))  in  June  2002. 

The  plan  calls  for  deployment  of  the  next  CPDLC  build  (CPDLC  IA)  beginning 
with  a  key  site  implementation  in  June  2003  followed  by  national 
implementation  within  the  next  several  months.  CPDLC  IA  will  expand  the 
message  set  to  support  speed,  heading,  altitude,  and  route  assignments.  In 
addition,  an  initial  capability  to  accommodate  downlinked  altitude  requests  will 
be  included. 

In  December  2004,  key  site  implementation  of  CPDLC  II  will  be  initiated  with 
national  deployment  commencing  thereafter.  This  system  build  will  constitute  a 
mature  version  of  CPDLC  capable  of  fully  supporting  ATC  operations  for  the 
next  several  years.  The  message  set  will  support  multipart  clearances,  report 
instructions,  and  an  enhanced  capability  for  flight  crews  to  downlink  requests 
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and  responses  to  ATC  queries.  CPDLC  III  is  a  far-term  (2010+)  version  of  the 
system  which  will  further  refine  air-ground  messaging  and  upgrade  to  a  more 
robust  communications  subnetwork. 

1.3  CPDLC  HUMAN  FACTORS  REQUIREMENTS. 

Successful  achievement  of  the  FAA’s  goals  in  each  of  the  implementation  phases 
outlined  above  will  depend  on  the  resolution  of  outstanding  human  factors  issues 
associated  with  CPDLC.  Focused  ground  side  and  flight  deck  research  efforts 
will  be  needed  to  define  HCI  requirements,  develop  supporting  procedures,  and 
insure  that  users  are  provided  with  effective  training  programs.  Additional 
high-fidelity  simulation  testing  with  both  pilots  and  controllers  in-the-loop  will 
be  required  to  validate  the  end-to-end  usability  and  functionality  of  the  system. 

The  rapid  progression  of  the  implementation  schedule  demands  that  the  human 
factors  issues  associated  with  each  phase  of  CPDLC  be  addressed  as  early  as 
possible  in  the  development  and  testing  process  in  order  to  have  a  meaningful 
effect  on  the  equipment,  software,  and  procedures  that  reach  the  field. 

1.4  NEAR-TERM  CONTROLLER  HUMAN  FACTORS  RESEARCH  PLANS. 


During  1999,  ACT-350  of  the  Technical  Center  intends  to  conduct  a  series  of 
studies  to  address  groundside,  ATC  human  factors  issues  associated  with  CPDLC 
I  and  IA.  The  overriding  goals  of  these  studies  will  be  to:  (1)  resolve  the 
controller  human  factors  issues  associated  with  CPDLC  I  prior  to  operational  test 
(OT)  in  2000;  (2)  insure  that  HCI  and  procedural  decisions  made  for  CPDLC  I  are 
compatible  with  the  requirements  for  future  system  builds  with  larger  message 
sets;  and  (3)  provide  HCI  and  service  design  criteria  for  CPDLC  IA  with 
sufficient  lead  time  to  effectively  impact  the  software  development  cycle. 

These  studies  will  take  place  concurrently  with  corresponding  flight  deck  test 
and  development  activities  and  will  lead  directly  to  joint  controller  and  pilot  in- 
the-loop  testing. 

The  near-term  ground  side  research  will  build  upon  over  10  years  of  prior  work 
conducted  by  ACT-350  at  the  Technical  Center.  Among  other  products,  this 
research  generated  a  set  of  thoroughly  tested  and  validated  CPDLC  services  for 
the  plan  view  display  (PVD)  workstation.  The  set  included  the  four  services 
included  in  CPDLC  I  (TC,  IC,  MT,  and  AS)  and  three  of  the  services  added  by 
CPDLC  IA  (altitude,  speed,  and  heading  assignments). 

Most  recently,  ACT-350  conducted  a  design  review  intended  to  obtain 
preliminary  controller  inputs  to  the  HCI  for  transitioning  the  CPDLC  services 
previously  implemented  on  the  PVD  to  the  Display  System  Replacement  (DSR) 
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workstation  (Darby,  1998).  Participants  including  controllers  from  the  Air 
Traffic  Data  Link  Validation  Team  (ATDLVT),  DSR  team,  and  National  Air 
Traffic  Controllers  Association  (NATCA)  examined  the  HCI  design  plans  and 
provided  recommendations  for  DSR  CPDLC  key  assignments,  full  data  block 
(FDB)  symbology,  display  parameters,  and  the  functionality  of  the  IC  service. 
Based  on  these  findings,  ACT-350  proceeded  to  incorporate  the  DSR  laboratory 
at  the  Technical  Center  into  the  Data  Link  test  bed  facilities  and  to  implement 
the  preliminary  designs  for  CPDLC  HCI  and  functionality  in  the  operational 
equipment. 

This  document  describes  the  findings  of  the  first  of  three  studies  that  will  be 
conducted  to  refine  the  controller  HCI  for  CPDLC  through  Build  IA,  validate 
proposed  CPDLC  procedures,  and  assess  controller  training  techniques.  The 
primary  purpose  of  this  first  study  was  to  provide  an  initial  review  of  the  CPDLC 
I  services  as  implemented  on  the  DSR,  and  to  obtain  controller  input  on  the 
design  of  the  route  assignment  and  downlink  services  needed  to  complete  the 
CPDLC  IA  package. 

2.  OBJECTIVES. 

The  specific  objectives  of  this  study  were  to: 

a.  Evaluate  the  acceptability  of  initial  DSR  HCI  and  functionality  for 
CPDLC  I  services  transferred  from  the  PVD. 

b.  Assess  initial  concepts  for  implementing  the  route  assignment  service 
and  for  handling  pilot  downlink  messages. 

c.  Examine  DSR  symbology  alternatives  for  FDB  session/eligibility 
symbols. 

3.  TEST  CONDUCT. 

3.1  TEST  PARTICIPANTS. 

The  participants  in  this  study  were  eight  ATC  Specialists.  Four  of  the  controllers 
were  en  route  members  of  the  ATDLVT  who  have  subject  matter  expertise  on 
ATC  Data  Link  communications.  The  ATDLVT  was  established  to  provide  user 
input  during  the  development  of  the  CPDLC  message  services  and  PVD  HCI 
design.  Each  of  the  controllers  assigned  to  the  team  participated  extensively  in 
the  design  process  and  has  many  hours  of  experience  in  using  CPDLC  during 
high  fidelity  simulation  studies. 
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Two  additional  controllers  were  drawn  from  an  air  traffic  team  that  had 
participated  in  the  DSR  development  process.  These  controllers  are  familiar 
with  the  DSR  HCI  and  associated  input  and  display  conventions. 

The  remaining  two  controllers  were  NATCA  representatives  who  Eire 
participating  in  the  CPDLC  implementation  process  and  a  Supervisory  ATC 
Specialist  from  the  Miami  ARTCC  (CPDLC  I  key  site). 

Informed  consent  to  participate  in  the  exercise  was  obtained  from  each 
participant  upon  arrival  at  the  Technical  Center.  The  consent  form  is  contained 
in  appendix  A  of  this  plan. 

3.2  TEST  FACILITIES  AND  AIRSPACE. 

The  study  took  place  at  the  Technical  Center  facilities  used  to  provide  high- 
fidelity  simulations  of  ATC  operations.  The  DSR  laboratory  houses  the  en  route 
controller  workstations  that  were  used  for  the  simulation  exercises  conducted 
during  this  study.  This  facility  is  configured  to  duplicate  a  field  installation, 
providing  direct  connection  to  the  Host  Computer  System  (HCS).  The  functions 
of  the  Data  Link  Applications  Processor  (DLAP)  were  emulated  by  a  Sun 
workstation.  The  Sun  workstation  also  inserted  time  delays  to  simulate  system 
transaction  and  pilot  response  delays  to  uplinked  CPDLC  messages. 
Transmission  delays  varied  over  the  upper  portion  of  the  range  specified  by  the 
CPDLC  I  specification.  The  one-way  transmission  delays  were  randomly 
selected  from  a  rectangular  distribution  ranging  from  6  to  11  seconds. 

Maximum  pilot  delays  were  determined  by  actual  pseudopilot  response  times. 
The  minimum  response  delay  permitted  by  the  system  was  5  seconds. 

Pilot  functions  were  provided  using  the  Dynamic  Simulation  (DYSIM)  training 
capability  of  the  Host.  Under  the  DYSIM  mode  of  operation,  pseudopilots 
working  from  DSR  consoles  had  the  ability  to  receive  and  send  Data  Link 
messages,  and  to  make  inputs  to  realistically  maneuver  aircraft  in  response  to 
controller  clearances. 

In  order  to  minimize  airspace  familiarization  and  training  requirements,  four 
contiguous  sectors  selected  from  the  ZCY  airspace  were  used  for  this  study. 

ZCY  is  a  generic  airspace  adaptation  used  for  technical  testing  in  the  DSR/HCS 
system.  Standardized  air  traffic  scenarios  previously  developed  for  ZCY  were 
employed  to  present  controllers  with  opportunities  to  exercise  the  CPDLC 
messaging  capabilities  in  the  context  of  dynamic  ATC  activity. 
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3.3  TEST  PROCEDURES. 


The  study  was  conducted  over  a  period  of  3  days.  Upon  arrival  at  the  Technical 
Center,  the  participants  received  an  overview  briefing  describing  the  objectives 
of  the  study,  the  activities  to  be  conducted,  and  their  responsibilities  in  assessing 
CPDLC  on  the  DSR. 

3.3.1  DSR  Familiarization. 

The  study  began  with  a  classroom  session  that  was  used  to  familiarize  the 
controllers  with  the  DSR  HCI.  The  intent  of  this  effort  was  to  provide  the 
participants  with  knowledge  of  the  display  and  input  conventions  used  in  DSR. 
Emphasis  was  placed  on  the  differences  between  the  PVD  and  DSR  controller 
interaction  requirements. 

The  participants  viewed  selected  lessons  from  the  DSR  Computer-Based 
Instruction  (CBI)  curriculum  in  a  group  session.  These  interactive  lessons  were 
presented  using  a  personal  computer  system  combined  with  the  DSR  trackball 
and  keyboard.  The  lessons  were  selected  to  focus  on  key  elements  of  the  display 
and  input  conventions  of  the  DSR. 

The  controllers  performed  DYSIM  hands-on  HCI  activities  in  the  DSR 
laboratory.  The  activities  were  derived  from  training  scenarios  developed  for 
DSR  which  require  controllers  to  exercise  all  major  DSR  interaction  skills. 

3.1.2  CPDLC  HCI  Familiarization. 

DSR  training  activities  were  followed  by  a  classroom  training  session  to 
familiarize  the  controllers  with  the  baseline  DSR  HCI  for  the  CPDLC  services 
originally  developed  for  the  Host/PVD  system.  The  session  presented  the 
proposed  DSR  keyboard  inputs  and  displays  associated  with  sending  TC,  MT, 
and  AS  messages,  monitoring  Data  Link  transactions  including  IC  errors,  and 
adjusting  Data  Link  settings. 

The  classroom  session  was  followed  by  two  practice  periods  in  the  DSR 
laboratory.  The  first  practice  period  presented  the  controllers  with  a  low  traffic 
scenario.  The  controllers  were  given  a  checklist  of  CPDLC  tasks  to  perform 
while  controlling  traffic.  These  tasks  required  the  controllers  to  exercise  all  of 
the  Data  Link  settings  controls,  send  the  transfer  of  communications  message 
using  both  the  manual  and  automatic  modes,  observe  the  FDB  displays  of 
transaction  status  and  equipage/eligibility,  and  experience  failure  displays 
including  “time-out”  and  IC  altitude  mismatches.  Each  pair  of  controllers 
alternated  between  the  positions  at  their  sector  in  order  to  provide  them  with 
experience  in  the  Radar  and  Data  controller  CPLDC  inputs. 
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The  first  practice  period  was  followed  by  a  brief  discussion  session  to  answer 
any  open  questions  about  the  baseline  CPDLC  HCI  and  the  rationale  that  guided 
its  design.  In  the  second  practice  session,  traffic  was  increased  to  provide  the 
controllers  with  a  more  realistic  experience  in  using  CPDLC  under  moderately 
high  workload  conditions.  As  in  the  first  session,  controllers  rotated  between  the 
Radar  and  Data  positions.  In  addition,  they  were  encouraged  to  experiment  with 
alternative  methods  of  sharing  CPDLC  communications  duties  between  the  two. 
positions.  During  the  last  hour  of  the  2-hour  session,  alternative  options  for  two 
of  the  Data  Link  FDB  symbols  were  exchanged  for  the  originals  in  order  to 
permit  the  controllers  to  examine  them. 

3.1.3  CPDLC  HCI  and  Functionality  Design  Review. 

A  detailed  evaluation  of  the  CPDLC  design  followed  the  second  practice  session. 
Each  controller  performed  an  independent  evaluation  by  completing  the 
questionnaire  items  contained  in  a  design  review  booklet  (appendix  B).  The 
booklet  structured  the  controller  evaluations  around  six  primary  topics:  (1)  Data 
Link  Keys;  (2)  Data  Link  FDB  and  Status  List  Displays;  (3)  TC;  (4)  MT;  (5)  IC; 
and  (6)  AS. 

The  displays  and  inputs  for  each  service  were  presented  for  individual  evaluation 
using  descriptive  text.  In  each  case,  the  controller  was  asked  to  provide  an 
overall  evaluation  of  each  service  design,  and  to  record  any  recommended  or 
required  design  modifications.  They  also  were  asked  several  specific  questions 
regarding  the  adequacy  of  displays  and  alerts,  the  workload  associated  with  data 
inputs  for  each  service  and  the  functional  compatibility  of  the  services  with 
existing  ATC  tasks  and  procedures. 

The  questionnaire  was  also  used  to  solicit  controller  opinions  regarding 
outstanding  CPDLC  design  issues.  The  confusability  and  acceptability  of  the 
alternative  symbol  set  available  in  the  DSR  were  rated  as  potential  replacements 
for  the  “hourglass”  used  in  the  FDB  to  indicate  Data  Link  equipage  and 
eligibility,  and  the  pound  sign  used  to  indicate  the  “sent”  status  of  TC  messages. 

3.1.4  Structured  Debriefing. 

The  individual  design  review  was  followed  by  a  structured  group  debriefing  and 
discussion  session.  The  session  was  used  to  perform  an  item-by-item  review  of 
the  controllers’  responses  to  the  design  review  questions  and  ratings.  The 
primary  emphasis  of  the  debriefing  was  to  identify  and  resolve  any 
disagreements  regarding  the  suitability  and  acceptability  of  the  CPDLC  I  HCI 
design.  In  addition,  the  debriefing  was  used  to  identify  improvements  that  could 
be  omitted  from  CPDLC  I,  but  were  desirable,  or  mandatory,  for  future  system 
builds. 
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The  group  discussion  was  documented  in  notes  recorded  by  test  personnel  and 
on  an  audiotape  record  for  reference  during  data  analysis  and  report 
preparation. 

3.1.5  Design  Generation  for  Route  Assignment  and  Downlink. 

CPDLC IA  will  include  two  services  that  have  not  been  previously  developed  and 
tested  on  the  PVD  workstation  (route  assignment  and  pilot  downlink).  For  this 
reason,  the  controllers  participated  in  a  structured  group  discussion  focused  on 
obtaining  a  preliminary  design  (or  set  of  design  options)  for  these  services  that 
can  be  implemented  in  the  test  bed  and  evaluated  in  a  future  study. 

The  controllers  were  first  presented  with  baseline  designs  for  the  services  in  a 
briefing  supported  by  illustrative  slides.  Discussion  topics  included  options  for 
route  assignment  data  entry  and  display  of  message  content,  as  well  as  options 
for  notifying  the  controller  of  a  pilot  downlink,  displaying  the  message,  and 
responding. 

The  controllers  returned  to  the  DSR  laboratory  to  observe  and  interact  with  the 
baseline  designs  during  an  ATC  scenario.  Finally,  the  group  participated  in  a 
critique  of  the  baseline  designs. 

The  results  of  the  design  generation  exercise  were  recorded  in  test  personnel 
notes.  In  addition,  an  audiotape  of  the  discussion  was  recorded  for  reference 
during  the  preparation  of  documentation  for  preliminary  designs. 

4.  RESULTS. 

4. 1  CPDLC  I  HCI  AND  FUNCTIONALITY. 

The  findings  presented  below  are  a  synthesis  of  the  inputs  that  were  obtained 
from  the  independently  written  controller  design  reviews  and  the  structured 
group  debriefing.  It  should  be  noted  that  the  design  review  and  debriefing 
focused  on  requirements  for  CPDLC  I.  Although  several  suggested 
modifications  were  considered,  the  group  indicated  that  the  majority  of  them 
could  be  deferred  to  CPDLC  IA.  The  distinction  between  changes  essential  for 
CPDLC  I  and  those  that  must  be  included  in  CPDLC  IA  is  maintained  in  the 
following  description  of  the  findings. 

4.1.1  Data  Link  Keys . 

The  locations  of  the  four  DSR  keys  that  were  evaluated  during  this  study  are 
shown  in  figure  1  below: 
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FIGURE  1.  DSR  DATA  LINK  KEYBOARD 

The  consensus  of  the  group  was  that,  for  CPDLC  I,  the  MT  UP  and  TC  UPkeys 
should  be  relocated  to  the  far  right  of  the  bank  of  12  hard-labeled  function  keys 
in  which  they  were  positioned  for  testing.  The  controllers  noted  that  this 
location  was  preferable  because  it  would  permit  rapid  access  to  the  keys  when 
making  entries  on  the  numeric  keypad  and  when  using  the  routinely  employed 
function  keys  located  in  the  six-key  bank  to  the  right  of  the  keyboard. 

.  A  majority  of  the  participants  agreed  that  the  Data  Link  key  labels  were 
meaningful  and  not  susceptible  to  confusion  with  other  key  designations.  While 
color  coding  of  the  key  caps  to  enhance  distinctiveness  was  discussed  during  the 
debriefing,  it  was  noted  that  two  colors  had  already  been  added  to  the  DSR  key 
caps,  and  that  proliferation  of  the  practice  may  diminish  the  value  of  color  as  an 
aid  to  key  identification. 

In  a  general  comment,  several  controllers  indicated  that,  in  some  cases,  there 
were  inconsistencies  among  abbreviations  used  to  refer  to  Data  Link  functions 
and  services  in  displays,  labels,  and  two-letter  Host  commands  (e.g.,  the  use  of 
both  TC  and  TOC  to  refer  to  transfer  of  communication.)  It  was  recognized  that 
some  of  these  might  be  impossible  to  modify  because  a  Host  command  may 
already  be  in  use  by  pre-existing  functions.  However,  the  group  suggested  that 
an  effort  be  made  to  improve  the  consistency  of  representations  used  in  displays 
and  labels  in  order  to  reduce  training  time  and  minimize  memory  demands. 

Finally,  when  asked  whether  it  would  be  acceptable  to  eliminate  the  Data  Link 
keys  and  require  controllers  to  access  their  functions  using  only  the  optional 
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two-letter  Host  commands,  the  participants  unanimously  agreed  that  the  keys 
were  required  to  reduce  workload  and  to  facilitate  rapid  Data  Link  entries. 

4.1.2  Data  Link  Settings. 

The  evaluated  design  for  adjusting  Data  Link  settings  used  a  pick  area  category 
key  C OS)  which  displayed  available  options  in  the  text  area  of  the  R-CRD.  These 
options  included  transfer  of  communication  mode  (man/auto) ,  menu  text  and 
status  lists  on/off,  and  various  menu  text  and  status  list  filtering  options.  One  of 
the  selectable  functions  (sector  settings)  displayed  the  current  selection  for  each 
of  the  options.  During  the  adjustable  duration  of  the  sector  settings  display, 
changes  could  be  made  and  displayed  dynamically  by  composing  messages 
using  two-letter  Host  commands. 

The  controllers  found  the  Data  Link  settings  display  and  functionality  non- 
intuitive  and  awkward  to  use.  When  making  the  setting  changes  by  pressing  DS, 
selecting  one  of  the  functions,  and  making  the  appropriate  entries,  no  feedback 
was  provided  to  indicate  the  results  of  the  input.  To  obtain  this  feedback,  the 
controller  had  to  press  DS  again,  and  select  sector  settings.  Alternatively,  if  the 
controllers  changed  the  settings  by  accessing  the  sector  settings  display  and 
making  the  adjustments  while  the  display  was  in  view,  they  were  required  to 
recall  the  entire  command  sequence  including  the  two-letter  Host  message. 

As  a  group,  the  controllers  argued  for  a  data  link  settings  display  that  would  (1) 
clearly  identify  each  function,  (2)  display  its  current  setting,  (3)  indicate  the 
available  options  for  the  setting,  (4)  cue  the  inputs  needed  to  make  a  change,  and 
(5)  provide  immediate  feedback  regarding  the  change  that  has  been  made. 

The  controllers  concurred  that  the  following  redesign  of  the  Data  Link  settings 
function  should  be  implemented  for  CPDLC I  to  provide  a  more  usable  system: 

a.  The  default  (hot)  function  under  the  DSkey  should  be  changed  to  the 
current  sector  settings. 

b.  All  other  functions  currently  displayed  under  DS  should  be  removed. 

c.  Typing  DS  Enter  or  “SN”  Enter  will  then  evoke  the  display  shown  on 
the  following  page  in  the  R-CRD  Text  Area.  This  display  is  a  modification  of  the 
current  sector  settings  display. 

As  before,  the  display  will  remain  in  the  text  area  for  an  adjustable  time 
parameter,  during  which  the  controller  can  make  changes  using  the  two-letter 
commands  shown  in  the  list.  The  SVCS  ON  display  is  controlled  by  the  facility 
and  cannot  be  changed  at  the  sector.  Because  of  display  space  limitations,  MT 
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SUPR/RECALL  will  not  show  the  menu  item  referents  that  are  suppressed. 
However,  inputs  made  to  suppress  or  recall  items  will  be  reflected  in  the  menu 
text  list  on  the  situation  display.  Changes  to  the  other  options  will  be 
immediately  displayed  to  the  controller  (e.g.,  OFF/ON  or  in  the  case  of  SL  SVCS 
SUPR  and  SL  STATES  SUPR  by  a  highlighted  display  of  those  services/states 
abbreviations  that  are  not  suppressed.)  In  the  example  shown  in  the  illustration, 
AS  messages  and  all  messages  in  the  SNT  and  ROG  states  are  suppressed  from 
the  status  list. 

The  two-letter  host  message  and  the  settings  options  (e.g.,  ON,  OFF,  IC,  AS, 
WIL)  are  presented  in  the  display  to  support  composition  of  the  inputs  needed  to 
modify  each  setting.  In  addition,  the  order  in  which  the  settings  Eire  listed  on  the 
display  is  modified  from  the  original  sector  settings  display  in  order  to  provide 
more  logical  groupings,  see  figure  2. 
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FIGURE  2.  DSR  R-CRD  DATA  LINK  SETTINGS 

Several  controllers  indicated  that  providing  for  trackball  access  to  the  sector 
settings  would  further  enhance  the  design  described  above.  Specifically,  they 
suggested  that  controllers  be  given  the  ability  to  toggle  among  the  setting 
options  by  trackball  selection  of  the  appropriate  list  item. 
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For  future  CPDLC  builds,  the  DSR  conventions  for  display  and  controller 
interaction  dictate  that  the  entire  data  link  settings  functionality  should  be 
implemented  in  the  Display  Control  (DC)  View.  The  DC  view  uses  a  matrix  of 
pick  keys  to  setup  the  sector  (brightness,  font,  map  size,  etc.)  The  pick  keys 
provide  selection  options  and  show  current  state.  The  controllers  recommended 
that  for  CPDLC  IA,  the  DC  view  should  be  explored  as  a  possibility  for 
implementing  all  Data  Link  settings.  Additionally,  Data  Link  settings  should  be 
incorporated  with  the  forthcoming  implementation  of  preference  options  that 
will  automatically  adjust  all  sector  settings  for  DSR  according  to  individual 
controller  default  selections. 

4.1.3  FDB  Symbols. 

After  observing  the  FDB  symbol  options  that  were  presented  during  the  CPDLC 
DYSIM  exercises,  a  clear  majority  of  the  controllers  indicated  that  changes 
should  be  made  for  CPDLC  I.  Seven  of  the  eight  controllers  rated  the  filled 
diamond  as  the  best  option  for  indicating  that  the  aircraft  is  equipped,  has  an 
active  session,  and  that  the  observing  controller  is  eligible  to  communicate  with 
the  aircraft.  The  eighth  controller  rated  the  filled  diamond  as  an  acceptable 
option,  and  the  original  hourglass  symbol  as  an  unacceptable  option.  Identical 
ratings  were  obtained  for  the  use  of  the  lightning  bolt  symbol  as  a  replacement 
for  the  pound  sign  to  indicate  that  a  transfer  of  communication  transaction  is  in 
progress. 

The  filled  diamond  was  judged  to  be  more  meaningful  than  the  hourglass,  as 
well  as  more  consistent  with  the  open  diamond  originally  used  to  indicate 
equipage/active  session  without  eligibility.  The  lightning  bolt  was  judged  to  be 
an  improvement  because  it  was  seen  as  an  inherently  meaningful  indication  of 
an  ongoing  transaction,  and  because  the  original  pound  sign  was  confusable 
with  the  coast  track  symbol. 

Several  of  the  controllers  noted  that  the  filled  diamond  and  lightning  bolt 
symbols  were  smaller  than  the  alphanumeric  font  used  in  the  FDB.  They 
indicated  that  this  could  present  problems  when  the  controller  selects  small  font 
sizes,  and  that  an  effort  should  be  made  to  increase  the  height  of  the  Data  Link 
symbols. 

4.1.4  Status  List  Alerts. 

The  group  concurred  that  the  abbreviations  used  to  indicate  transaction  status 
were  clear  and  easy  to  understand.  However,  the  controllers  were  unanimous  in 
their  judgment  that  the  “abnormal”  status  indications  (NEG,  UNA,  FAI,  ERR,  and 
TIM)  were  not  sufficiently  obvious  to  reliably  alert  the  controller  and  prompt  any 
needed  action. 
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During  the  debriefing,  it  was  agreed  that  the  alerting  value  of  these  indicators 
must  be  improved  for  CPDLC I.  Suggested  alternatives  for  improving  the 
salience  of  these  alerts  in  the  status  list  included  the  use  of  color,  reverse  text,  or 
possibly  blinking  of  the  status  abbreviation.  A  brightness  increase  was  judged  to 
be  a  less  desirable  option  because  it  would  loose  its  distinctiveness  when 
controllers  select  a  high  level  of  ambient  brightness  for  the  status  list. 

4.1.5  Transfer  of  Communication. 

The  controllers  were  generally  satisfied  with  the  available  options  for  sending 
manual  TC  messages,  modifying  hand  off  commands  to  alter  TC  uplinks,  and 
selectively  overriding  the  TC  mode. 

The  tested  functionality  provided  for  acquiring  (stealing)  Data  Link  eligibility 
from  another  sector  required  a  second  command  to  uplink  the  new  sector’s  voice 
radio  frequency  to  the  aircraft.  The  group  recommended  that  a  combined 
command  be  made  available  for  future  evaluation. 

The  tested  design  provided  an  ability  to  release  Data  Link  eligibility  in  order  to 
compensate  for  controllers  who  choose  not  to  use  the  CPDLC  capability.  In  this 
design,  the  non-using  controller  must  make  inputs  to  pass  eligibility  to  the  next 
sector  after  completing  the  handoff  and  voice  transfer  of  communication  (RE 
FLID  or  DL  FLID) . 

The  group  expressed  concern  that,  for  various  reasons,  the  non-using  controller 
may  fail  to  carry  out  the  release  action.  This  would  result  in  additional  workload 
for  the  receiving  controllers  and  potentially  nullify  any  benefits  that  would 
otherwise  be  associated  with  their  use  of  Data  Link.  For  future  CPDLC  builds,  it 
was  recommended  that  efforts  should  be  invested  in  designing  support  features 
that  would  ensure  that  non-using  controllers  would  make  the  release  entries. 

One  of  the  controllers  suggested  that  a  list  be  built  with  the  FLIDs  of  aircraft 
requiring  Data  Link  eligibility  release,  and  that  the  release  command  be 
accomplished  by  a  trackball  select  of  the  list  entry. 

4.1.6  Menu  Text. 

The  controllers  did  not  identify  any  changes  to  the  menu  text  functionality  or 
HCI  that  will  be  required  for  fielding  CPDLC  I.  However,  three  improvements 
for  future  system  builds  were  recommended. 

The  controllers  indicated  that  the  MT  UP  should  be  an  implied  input  when  the 
trackball  is  used  to  select  a  menu  text  item  and  the  aircraft’s  position  symbol  as 
a  method  for  sending  a  message.  Additionally,  the  controllers  suggested  that 
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the  MT  list  (as  well  as  the  status  list)  might  be  more  effectively  implemented  as 
DSR  views  than  as  Host  lists.  This  modification  would  make  Data  Link 
functionality  consistent  with  the  view-oriented  DSR  display  conventions,  and 
would  provide  the  semi-opaque  view  display  capability  and  the  ease  of 
interaction  offered  by  DSR.  Finally,  the  group  agreed  that  an  automation 
enhancement  to  the  menu  text  functionality  would  be  desirable  in  future  builds. 
This  enhancement  would  permit  controllers  to  select  a  temporary  MT  message 
that  would  be  automatically  uplinked  to  every  aircraft  that  made  an  initial 
contact  with  their  sector.  The  addition  of  this  feature  would  reduce  the 
workload  associated  with  sending  every  aircraft  important,  but  repetitive 
information,  required  when  specific  conditions  pertain  in  the  sector  (e.g.,  a 
temporary  weather  situation) . 

4.1.7  Additional  Issues. 

The  controllers  were  asked  several  general  questions  both  in  the  individual 
design  review  and  during  the  group  debriefing.  The  findings  obtained  from  their 
responses  are  discussed  in  the  following  paragraphs. 

a.  List  Position  Indicators 

In  a  general  evaluation  of  Data  Link  lists,  the  group  noted  that  the 
position  at  which  the  status  list  will  appear  on  the  situation  display  should  be 
indicated  when  no  transactions  are  in  progress  and  when  the  list  is  suppressed. 
Likewise,  controllers  should  have  an  indication  of  the  location  of  menu  text  list 
when  it  is  suppressed. 

b.  Transaction  Delays 

The  controllers  were  asked  whether  they  felt  that  the  total  transaction 
delays  that  they  experienced  during  the  Data  Link  DYSIM  exercises  were  short 
enough  to  support  effective  use  of  CPDLC  I  in  the  field.  None  of  the  controllers 
felt  that  these  delays  that  were  derived  from  the  CPDLC  I  specification  were 
excessive,  or  that  they  would  limit  the  use  of  the  four  initial  services  in  the  field. 
However,  several  of  the  controllers  noted  that  these  delays  should  be  more 
thoroughly  examined  in  future  studies  with  more  realistic  air  traffic  scenarios. 

c.  Training 

The  controllers  were  asked  two  questions  regarding  training 
requirements  for  CPDLC  I.  When  asked  whether  the  Data  Link  training  that 
they  received  during  the  test  was  adequate  for  this  initial  evaluation,  a  majority 
indicated  that  their  introduction  was  acceptable.  However,  all  agreed  that 
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additional  hands-on  practice  with  a  fully  functional  system  would  be  needed  for 
future  high  fidelity  simulation  studies. 

The  controllers  also  were  asked  for  an  initial  assessment  of  current  operational 
training  plans  for  CPDLC I.  These  plans  call  for  a  program  consisting  of  a  1- 
hour  overview  lecture,  4  hours  of  CBI,  a  2-hour  procedures  lecture,  and  6  hours 
of  DYSIM  exercises.  Three  of  the  controllers  indicated  that  this  level  of  training 
probably  would  be  appropriate.  The  remaining  participants  felt  that  they  were 
unable  to  make  a  meaningful  judgment  at  this  time. 

d.  Radar  Associate  Position  Functionality 

The  controllers  unanimously  agreed  that  enhanced  DSR  functionality 
would  be  needed  for  the  D-side  in  future  CPDLC  builds.  Specifically,  the  group 
argued  that  the  D-side  controller  would  find  it  difficult  to  monitor  Data  Link 
transactions  using  the  status  list  provided  at  the  R-side  position.  Likewise,  it 
was  suggested  that  the  lack  of  category  keys  would  place  additional  memory 
demands  on  the  D-side  controller.  The  group  recommended  that  the  D-side  be 
provided  with  a  status  list.  Where  possible,  the  group  also  recommended  that 
category  key  functionality  be  provided  at  the  D-side,  either  through  the  addition 
of  keyboard  keys,  or  by  including  a  category  key  pick  area  in  the  D-CRD. 

4.2  DESIGNS  FOR  NEW  CPDLC  IA  SERVICES. 

4.2.1  Route  Assignment. 

The  controllers  were  presented  with  a  baseline  design  for  the  route  assignment 
service  in  an  introductory  lecture,  and  were  then  given  the  opportunity  to 
dynamically  exercise  the  design  in  a  DYSIM  session.  The  baseline  design  made 
use  of  the  existing  Host  inputs  for  route  assignment.  Inputs  currently  used  to 
update  the  NAS  for  a  route  clearance  are  modified  by  the  addition  of  an  “S”  at 
the  end  of  the  command  to  send  the  clearance  via  Data  Link.  The  controllers 
indicated  that  the  baseline  design  for  the  route  assignment  service  was 
acceptable  as  demonstrated  in  the  test  bed.  However,  they  also  recommended 
that  it  should  also  be  possible  to  send  route  assignments  using  the  menu  text 
functionality. 

4.2.2  Altitude  Request  Downlinks. 

In  addition  to  the  route  assignment  service,  the  controllers  were  presented  a 
candidate  design  for  processing  and  responding  to  altitude  requests  downlinked 
from  the  flight  deck.  In  the  baseline  design,  the  presence  of  a  pending  downlink 
is  signaled  by  replacing  the  Data  Link  symbol  in  the  FDB  with  a  down-arrow.  To 
view  the  open  downlinks  from  any  aircraft,  the  controller  enters  “DW”  FLID.  A 
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list  appears  for  the  aircraft,  which  displays  all  outstanding  downlinks,  the  time  of 
receipt,  and  a  suggested  positive  response  (e.g.,  CTAM  FL370).  The  controller 
can  respond  by  typing  “S”  (Send),  “U”  (Unable),  “Y”  (Standby),  or  “D”  (Delete 
message),  selecting  the  message  in  the  list  with  the  trackball,  and  pressing 
ENTER.  Pressing  “S”,  “U”,  or  “Y”  creates  an  entry  in  the  status  list  for  the 
uplinked  response  and  deletes  the  request  from  the  downlink  list.  Pressing  “D” 
removes  the  request  from  the  list,  and  does  not  send  an  uplink  message.  The 
controller  can  also  view  outstanding  requests  from  all  aircraft  in  the  sector  by 
typing  “DW”  ENTER.  Inputs  identical  to  those  described  above  can  be  used  to 
formulate  and  send  a  response. 

The  controllers  agreed  upon  a  number  of  modifications  to  the  baseline  downlink 
HCI.  The  group  noted  that  controllers  must  be  given  an  indication  of  the 
position  at  which  a  downlink  list  will  appear  on  the  situation  display  prior  to 
requesting  the  list. 

In  addition,  they  recommended  that  the  format  of  items  shown  in  the  display  be 
modified.  Specifically,  the  aircraft’s  computer  identification  (CID)  should  be 
presented  first  as  the  item  referent,  and  the  time  of  receipt  should  be  the  last 
entry  on  the  first  line  of  each  item.  Multiple  messages  should  be  presented  in 
chronological  order  of  receipt,  and  when  multiple  messages  from  a  single 
aircraft  exist,  the  CID  should  be  followed  by  an  alphabetic  suffix  to  uniquely 
identify  the  message. 

The  controllers  also  recommended  that  the  time  delay  be  minimized  between  an 
entry  to  send  a  response  and  the  removal  of  the  message  from  the  downlink 
list/appearance  in  the  status  list. 

Finally,  the  controllers  unanimously  agreed  that  the  D  position  be  given  full  and 
independent  capabilities  to  process  downlinks.  That  is,  the  D-side  should  have 
an  ability  to  request  a  downlink  list  that  is  displayed  in  the  D-CRD  for  any  single 
aircraft  or  for  all  aircraft.  D-side  requests  for  a  downlink  list  should  not  present 
a  list  on  the  R-side. 

5.  CONCLUSIONS  AND  RECOMMENDATIONS. 

The  primary  results  of  this  study  constitute  an  initial  evaluation  of  the  air  traffic 
controller’s  Human-Computer  Interface  (HCI)  and  functionality  for  the  four 
services  provided  by  Controller-Pilot  Data  Link  Communications  (CPDLC)  Build 
I  (CPDLC  I).  The  study  also  generated  initial  requirements  for  the  design  of  two 
additional  services  that  will  be  provided  by  CPDLC  Build  IA  (CPDLC  IA).  All 
assessments  were  based  on  structured  observations  made  by  eight  air  traffic 
controllers  after  exercising  the  services  on  the  Display  System  Replacement 
(DSR)  under  dynamic  simulation  conditions. 
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5.1  CPDLC I. 


The  following  recommendations  are  based  on  the  results  of  the  individual  design 
reviews  and  group  debriefing  conducted  during  this  study.  These 
recommendations  are  divided  into  two  categories.  The  first  category  identifies 
design  modifications  judged  by  the  controller  participants  to  be  essential  to  the 
successful  deployment  of  CPDLC  I  during  the  limited  key  site  implementation. 
The  second  category  of  recommendations  consists  of  design  changes  that,  while 
not  considered  essential  for  CPDLC  I,  will  be  mandatory  for  inclusion  in  future 
system  builds  beginning  with  CPDLC  IA. 

5,1.1  Required  Design  Modifications  for  CPDLC  I. 

a.  Non-Normal  Status  Alerts 

The  alerting  characteristics  of  non-normal  message  status  indications  in 
the  status  list  must  be  improved.  When  a  message  is  in  the  NEG,  UNA,  FAI,  ERR 
or  TIM  state,  the  status  list  entry  should  be  emphasized  in  some  manner  to 
reliably  alert  the  controller  and  prompt  any  needed  action.  Recommended 
alternatives  for  testing  include  the  use  of  color,  reverse  text,  or  blinking. 

b.  Full  Data  Block  Symbols 

The  symbol  used  to  indicate  Data  Link  eligibility  should  be  changed  from 
an  hourglass  to  a  filled  diamond.  The  symbol  used  to  indicate  an  ongoing 
transfer  of  communication  should  be  changed  from  a  pound  sign  to  a  lightning 
bolt. 


c.  Data  Link  Settings 

The  design  of  the  controller  interface  used  to  modify  Data  Link  settings 
must  be  improved  to  permit  more  efficient  and  accurate  controller  performance. 
As  a  minimum,  the  alternative  design  described  and  illustrated  in  section  4.1.2  of 
this  report  should  be  adopted  for  CPDLC  I. 

d.  Data  Link  Key  Location 

The  MT  UP  and  TC  L'Pkeys  should  be  relocated  to  the  far  right  of  the 
12-key  hard  function  key  pack. 
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5.1.2  Design  Modifications  That  Can  Be  Deferred  to  CPDLC  IA. 

a.  Data  Link  Settings 

*  The  functionality  provided  to  adjust  Data  Link  settings  should  be  further 
improved.  As  a  minimum,  controllers  should  be  provided  with  the  ability  to  use 
the  trackball  and  trackball  keys  to  toggle  among  the  options  for  each  setting. 
Optimally,  Data  Link  settings  should  be  incorporated  with  the  DSR  DC  view. 

b.  Implied  Commands 

The  TC  UP  and  MT  £ZP  commands  should  not  be  required  when  the 
controller  uses  the  trackball  to  select  held  transfer  of  communication  messages 
or  menu  text  items  and  to  designate  the  FLID. 

c.  Data  Link  Lists 

The  status  list  and  menu  text  list  should  be  converted  to  DSR  views. 

d.  Releasing  Data  Link  Eligibility 

Support  features  should  be  developed  to  help  ensure  that  a  controller 
who  is  not  using  CPDLC  will  make  the  necessary  inputs  to  release  Data  Link 
eligibility  to  the  next  sector  for  each  equipped  aircraft. 

e.  D-Side  CPDLC  Capabilities 

The  associate  radar  controller  (D-Side)  is  expected  to  assume  a  major 
role  in  the  use  of  Data  Link.  For  this  reason,  the  D-side  should  be  provided  with 
enhanced  CPDLC  control  and  display  capabilities.  Specifically,  this  control 
position  should  have  a  repeater  of  the  status  list  and  dedicated  CPDLC  keys  on 
the  keyboard  and  in  a  pick  area  on  the  D-CRD. 

f.  Data  Link  Symbols 

The  heights  of  the  Data  Link  symbols  in  the  FDB  should  be  increased 
over  those  used  in  the  present  study  to  insure  that  they  are  discriminable  when 
the  controller  selects  small  font  sizes. 

5.2  REQUIREMENTS  FOR  ROUTE  ASSIGNMENT  AND  DOWNLINK 
SERVICES. 

The  controller  participants  recommended  modifications  to  the  baseline  designs 
for  the  route  assignment  and  downlink  services.  These  recommendations  are 
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recorded  in  section  4.2  of  this  report.  The  modifications  should  be  incorporated 
in  the  Data  Link  test  bed  and  evaluated  in  future  studies. 
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ABBREVIATIONS  AND  ACRONYMS. 


ACARS 

ARTCC 

AS 

ATC 

ATCS 

ATDLVT 

ATN 

CBI 

CID 

CPDLC 

DC 

DLAP 

DSR 

DYSIM 

FAA 

FDB 

HCI 

HCS 

IC 

MT 

NATCA 

OT 

PVD 

R-CRD 


ARINC  Communications  Addressing  and  Reporting  System 

Air  Route  Traffic  Control  Center 

Altimeter  Setting 

Air  Traffic  Control 

Air  Traffic  Control  Specialist 

Air  Traffic  Data  Link  Validation  Team 

Aeronautical  Telecommunications  Network 

Computer-Based  Instruction 

Computer  Identification 

Controller-Pilot  Data  Link  Communications 

Display  Control 

Data  Link  Applications  Processor 
Display  System  Replacement 
Dynamic  Simulation 
Federal  Aviation  Administration 
Full  Data  Block 
Human  Computer  Interface 
Host  Computer  System 
Initial  Contact 
Menu  Text 

National  Air  Traffic  Controllers  Association 

Operational  Test 

Plan  View  Display 

Radar  Computer  Readout  Device 
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APPENDIX  A 


INDIVIDUAL’S  CONSENT  TO  VOLUNTARY  PARTICIPATION  IN  A 

RESEARCH  PROJECT 


APPENDIX  A 


INDIVIDUAL’S  CONSENT  TO  VOLUNTARY  PARTICIPATION  IN  A 

RESEARCH  PROJECT 

I  ,  understand  that  this  study  entitled 

“Controller  Evaluation  of  Controller-Pilot  Data  Link  Communication  (CPDLC) 
Services  implemented  on  the  Display  System  Replacement  (DSR)  Workstation” 
is  sponsored  by  the  Federal  Aviation  Administration  (FAA)  and  is  being  directed 
by  the  Data  Link  Branch  (ACT-350)  of  the  Communications,  Surveillance  and 
Navigation  Division. 

I  have  been  recruited  to  volunteer  as  a  participant  in  the  project  named  above. 
The  purpose  of  this  project  is  to  obtain  expert  controller  input  regarding  the 
design  of  the  inputs  and  displays  that  were  used  to  provide  a  CPDLC  capability 
on  the  DSR  controller  workstation. 

Nature  and  Purpose 

The  project  will  involve  my  participation  over  a  period  of  4  days.  There  will  be 
approximately  seven  other  en-route  Air  Traffic  Control  Specialists  (ATCSs) 
participating  with  me.  The  project  activities  will  take  place  during  normal 
workdays  with  breaks  for  meals.  I  will  be  required  to  attend  classroom  training 
sessions  and  practice  sessions  in  the  air  traffic  control  (ATC)  simulation 
laboratories  to  acquaint  me  with  Data  Link  and  the  DSR.  I  will  then  perform  an 
individual  evaluation  of  the  CPDLC  human-computer  interface  (HCI),  and 
participate  in  a  group  debriefing.  I  will  also  participate  in  group  discussions  to 
generate  candidate  designs  for  additional  services  and  to  assess  draft  CPDLC 
procedures. 

Study  Procedures 

The  study  will  begin  with  a  classroom  training  session  on  the  DSR  HCI  followed 
by  the  dynamic  simulation  (DYSIM)  practice.  Next,  I  will  receive  training  on  the 
CPDLC  HCI  followed  by  simulation  exercises  in  the  ATC  simulation  laboratory 
to  familiarize  me  with  the  Data  Link  commands  and  displays  as  implemented  on 
the  plan  view  display  (PVD).  I  will  use  these  experiences  as  a  basis  for 
completing  an  individual  design  review  of  the  proposed  CPDLC  HCI  for  DSR. 
The  design  review  booklet  will  provide  a  description  of  each  design  feature  and 
provide  space  for  my  comments  and  recommendations.  The  review  will  conclude 
with  a  structured  group  debriefing  to  identify  individual  areas  of  concern  and  to 
achieve  consensus  where  possible. 
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Finally,  I  will  participate  in  two  organized  discussion  sessions  to  make 
recommendations  for  the  design  of  two  additional  services  and  to  evaluate  draft 
procedures  for  the  use  of  CPDLC  in  the  field. 

Discomfort  and  Risks 

I  understand  that  there  are  minimal  physical  or  psychological  risks  associated 
with  participation  in  this  study.  The  simulation  facilities  use  equipment  and 
workstations  that  are  identical  to  those  currently  used  by  en  route  controllers  in 
Air  Route  Traffic  Control  Centers  (ARTCCs).  The  tasks  that  I  will  perform  in  the 
laboratories  will  be  the  same,  or  similar,  to  those  I  perform  in  my  job  as  an 
ATCS. 

Precautions  for  Female  Participants 

The  risks  of  participating  in  this  study  are  substantially  the  same  as  those 
encountered  by  operational  en  route  ATCSs  performing  their  normal  duties.  If  I 
am  a  female  ATCS,  I  understand  that  I  must  exercise  the  same  precautions  that  I 
would  at  my  job  to  avoid  risks  to  myself,  the  embryo  or  fetus  if  I  currently  am,  or 
may  become  pregnant. 

Benefits 

I  understand  that  the  only  direct  benefit  to  me  is  that  I  will  receive  my  normal 
FAA  pay  and  travel  reimbursement  while  participating  in  this  study. 

Participant  Responsibilities 

I  understand  that  by  volunteering  for  this  study  that  I  accept  the  obligation  to 
make  an  honest  evaluation  of  the  CPDLC  HCI  for  DSR  based  on  my  past 
experience  as  an  en  route  ATCS  and  on  the  information  and  simulation 
experiences  that  are  provided  to  me  during  this  study. 

Compensation  and  Injury 

I  agree  to  report  any  personal  injury  or  suspected  adverse  effect  of  this  study  to 
Mr.  Darby  at  609-485-6345.  I  understand  that,  as  an  official  government 
employee  duty,  accident  insurance  coverage  for  this  study  activity  is  provided  by 
the  Workmen’s  Compensation  Insurance  Fund  in  relation  to  my  Federal 
Government  employment. 
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Participant’s  Assurances 

I  understand  that  my  participation  in  this  study  is  completely  voluntary.  I  am 
participating  because  I  want  to.  Mr.  Darby  has  adequately  answered  any  and  all 
questions  that  I  have  about  this  study,  my  participation,  and  the  procedures 
involved.  I  understand  that  Mr.  Darby  will  be  available  to  answer  questions 
concerning  procedures  throughout  this  study. 

I  have  not  given  up  any  of  my  legal  rights  or  released  any  individual  or 
institution  from  liability  for  negligence. 

I  understand  that  records  of  this  study  will  be  kept  confidential,  and  that  I  will 
not  be  identifiable  by  name  or  description  in  reports  or  publications  about  this 
study. 

I  understand  that  I  may  withdraw  from  this  study  at  any  time  without  penalty  or 
loss  of  benefits  to  which  I  am  otherwise  entitled. 

If  I  have  questions  about  this  study  or  need  to  report  adverse  effects  from  the 
study  activities,  I  will  contact  Mr.  Darby  at  609-485-6345  during  the  workday  or 
1-800-832-2506  at  other  times. 

I  have  read  this  consent  document.  I  understand  its  contents,  and  I  freely 
consent  to  participate  in  this  study  under  the  conditions  described.  I  have 
received  a  copy  of  this  consent  form. 


Study  Participant: 


Date: 


Investigator: 


Date: 


Witness: 


Date: 
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APPENDIX  B 


CONTROLLER  EVALUATION  MATERIALS 


DISPLAY  SYSTEM  REPLACEMENT  (DSR) 

CPDLC  I  HUMAN-COMPUTER  INTERFACE 

CONTROLLER  DESIGN  REVIEW  BOOKLET 

This  booklet  contains  a  series  of  questions  that  will  permit  you  to  independently 
review  and  evaluate  the  CPDLC  I  Human-Computer  Interface  (HCI)  that, will  be 
implemented  on  the  DSR.  The  goals  of  this  review  are  to  identify  those  aspects 
of  the  HCI  that  will  be  acceptable  as  presented,  or  will  require  modification  prior 
to  fielding. 

Please  answer  all  of  the  questions  in  this  booklet  and  carefully  record  your 
comments  and  any  recommendations  for  design  changes.  Please  explain  your 
reasons  for  suggesting  any  changes. 


Reviewer’s  Name 
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Instructions 


This  booklet  is  divided  into  six  parts  that  will  permit  you  to  make  a  detailed 
evaluation  of  the  functionality  provided  by  CPDLC  I  and  the  controller  interface 
design.  Each  part  begins  with  a  design  description.  Read  these  descriptions 
carefully  before  answering  the  associated  questions  and  recording  your 
comments. 

NOTES  ON  CONVENTIONS  USED  IN  THE  DESIGN  DESCRIPTIONS 

-  Data  as  shown  in  a  display  or  entered  on  the  keyboard  are  presented  in 
quotation  marks.  When  spaces  are  required,  they  are  included  within  the 
quotation  marks.  The  quotation  marks  are  not  part  of  the  display  or 
entry. 

-  All  spaces  included  within  quotation  marks  for  keyboard  entries  are 
mandatory.  For  example,  "MT  ON"  should  be  interpreted  as  typing  MT,  a 
space,  and  ON. 

-  Input  commands  printed  in  bold  italics  refer  to  a  DSR  keyboard  category, 
soft  function,  or  hard  function  key,  or  a  “key”  in  the  R-CRD 

Category  Selection  Area  (e.g.  DL,  DS,  FI). 

-  Two  trackball  keys  are  used.  Trackball  ENTER  (middle  key)  is 
used  to  complete  a  command  sequence.  Trackball  SELECT  (left 

key)  is  used  to  identify  an  item  in  the  R-CRD  text  area  or  the  status  list 
and  to  identify  lists  for  moving  them  on  the  display. 

-  FLID  refers  to  any  NAS  command  for  identifying  a  flight 
including: 


.  The  Aircraft  Identification  Call  Sign  (AID) 

.  The  Computer  Identification  Number  (CID) 

.  The  Beacon  Code 

.  Positioning  the  trackball  cursor  over  the  data 
block  and  pressing  trackball  ENTER 


All  keyboard  entries  must  be  followed  by  a  keyboard  ENTER  or  a  trackball 
ENTER  to  complete  the  command  sequence. 
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Part  I 


Data  Link  Keys 

The  CPDLC I HCI  for  DSR  uses  three  dedicated  keyboard  keys  and  two  “pick” 
keys  in  the  R-CRD  category  selection  area.  The  Data  Link  (. DL )  keyboard  and 
pick  keys  are  used  to  send  some  messages,  delete  messages,  transfer  eligibility, 
and  initiate  or  terminate  a  Data  Link  session  with  an  aircraft.  The  Data  Link 
Settings  (DS)  pick  key  is  used  to  set  the  Transfer  of  Communications  mode, 
display  and  modify  a  list  of  current  sector  Data  Link  settings,  and  to  select  or 
modify  the  contents  of  Data  Link  lists.  The  two  remaining  keyboard  keys  are 
used  to  uplink  a  transfer  of  communication  message  in  the  “held”  status  ( TC 
UP),  and  to  send  a  message  contained  in  the  menu  text  list  (MT  UP). 

The  current  locations  for  these  keys  and  the  function  key  menu  that  is  presented 
in  the  R-CRD  category  selection  area  when  the  DL  or  DS  keys  are  pressed  are 
shown  in  the  following  diagrams: 
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DL  category  menu: 


RELEASE  ELIGIBILITY 

RL 

FI 

UPLINK  FREQUENCY 

UF 

F2 

ACQUIRE  ELIGIBILITY 

AL 

F3 

END  SESSION 

ED 

F4 

DELETE  MESSAGE 

DE 

F6 

START  SESSION 

SD 

F7 

DYSIM  RESPONSE 

JU 

F9 

DYSIM  MENU 

JN 

F10 

RELEASE  ELIGIBILITY:  Sends  eligibility  to  another  sector  that  has  track 
control  (NOTE:  two-letter  command  in  the  Test  Bed  is  RE) 

UPLINK  FREQUENCY:  Sends  your  frequency  to  an  aircraft 
ACQUIRE  ELIGIBILITY:  Transfers  eligibility  to  your  sector  if  you  have 
track  control  (NOTE:  two-letter  command  in  Test  Bed  is  SX) 

END  SESSION:  Manually  terminates  a  data  link  session  with  an  aircraft 
DELETE  MESSAGE:  Deletes  a  transaction  shown  in  the  status  list 
START  SESSION:  Manually  initiates  a  data  link  session  with  an  aircraft 
DYSIM  RESPONSE:  Training  function 
DYSIM  MENU:  Training  function 


PS  category  menu: 


TOC  MODE 

AT 

FI 

SECTOR  DL 

XX 

F2 

MENU  TEXT  LIST 

MT 

F3 

SUPP/RECALL  MT 

MS 

F4 

SECTOR  SETTINGS 

SN 

F7 

SL  SERVICES 

SV 

F8 

STATUS  LIST 

SL 

F9 

SL  STATES 

SZ 

F10 

TOC  MODE:  Used  to  set  TOC  to  AUTO  or  MANUAL 

SECTOR  DL:  Turns  Data  Link  off  or  on  at  sector 

MENU  TEXT  LIST:  Permits  suppression  or  recall  of  entire  MT  list 

SUPP/RECALL  MT:  Permits  suppression  or  recall  of  individual  permanent 

items  in  the  MT  list 
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SECTOR  SETTINGS:  Displays  all  current  settings  for  functions  in  the  DS 
category  menu  for  X  seconds.  These  can  be  modified  while  the  list  is  displayed 
by  using  the  alternative  two-letter  inputs  for  invoking  the  functions. 

SL  SERVICES:  Permits  filtering  the  contents  of  the  SL  by  service  type 
STATUS  LIST:  Permits  suppressing/retrieving  the  entire  status  list 
SL  STATES:  Permits  filtering  the  contents  of  the  SL  by  transaction  status 

CPDLC I  Key  Evaluation 
Questions: 

1.  Are  the  locations  of  the  Data  Link  keys  on  the  keyboard  (DL,  MT  UP, 

TC  UP)  and  in  the  R-CRD  “pick”  area  (DL,  DS)  acceptable  for  the 
functions  that  they  serve? 


2.  Are  the  abbreviations  used  to  label  the  Data  Link  keys  meaningful 
and  not  susceptible  to  confusion  with  other  key  designations  used  in 
DSR? 


3.  Are  the  Data  Link  functions  appropriately  grouped  under  the  DL  and 
Z>Skeys? 


4.  Are  the  items  shown  on  the  R-CRD  when  the  DL  and  DS  keys  are 
pressed  unambiguous  and  do  they  adequately  indicate  the  functions 
that  they  will  perform? 
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5.  If  the  Data  Link  keys  (DL,  DS,  TC  UP,  MT  UP)  were  not  available, 
would  it  be  acceptable  to  perform  these  functions  using  the  alternative 
two-letter  Host  commands  only? 


6.  Are  “RELEASE  ELIGIBILITY”  and  “TOC  MODE”  appropriate  choices  for  the 
“hot”  key  under  the  DL  and  DS  keys? 


Overall  Rating  of  Data  Link  keys: 

THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  DESIRABLE  OR  NEEDED 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  NEEDED  BUT  THE  FOLLOWING 
MODIFICATIONS  OR  IMPROVEMENTS  WOULD  BE 
DESIRABLE: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  UNACCEPTABLE— 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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Part  II 


Status  List  and  Full  Data  Block 

-  Function 

The  Full  Data  Block  (FDB)  provides  unique  graphic  characters  which  indicate 
that  an  aircraft  is  equipped  to  receive  Data  Link  messages  and  has  an  active  Data 
Link  session,  and  whether  the  observing  control  position  is  eligible  to  uplink 
messages  to  the  aircraft.  The  FDB  also  provides  limited  information  about  the 
status  of  ongoing  Data  Link  transaction. 

The  status  list  is  a  Host  situation  display  tabular  list  that  contains  full 
information  about  the  content  and  current  status  of  ongoing  Data  Link 
transactions.  The  status  list  does  not  appear  on  the  D  position  display. 

-  Full  Data  Block  Equipage  and  Eligibility  Indicators 

Data  Link  equipage/session  and  eligibility  are  indicated  by  graphic  characters 
located  in  the  first  position  of  the  first  line  of  the  FDB.  No  special  character  in 
this  position  identifies  an  aircraft  that  is  not  capable  of  communicating  via  Data 
Link  or  does  not  have  an  active  Data  Link  session.  An  open  diamond  (0 
indicates  that  the  aircraft  is  Data  Link  equipped  and  has  an  active  session,  but 
that  the  viewing  sector  position  is  ineligible  to  communicate  with  it.  An  “hour 
glass”  (  )  indicates  that  the  aircraft  is  equipped  with  X  an  active  session,  and 
that  the  viewing  sector  is  eligible. 

Data  Link  sessions  with  aircraft  are  normally  established  and  terminated  by 
automation.  The  controller  can  manually  establish  an  active  session  with  an 
aircraft  that  has  logged-on  to  the  Data  Link  system  by  entering  DL  F7,  or  typing 
“SD”,  followed  by  the  FLID.  A  session  can  be  terminated  by  entering  DL  F4,  or 
typing  “ED”,  followed  by  the  FLID. 

-  Status  List  Format 

The  status  list  is  identified  by  "SL"  displayed  in  the  header  area  of  the  list.  Each 
line  of  the  list  contains  information  about  one  ongoing  transaction.  A  line  has 
three  data  fields  displaying  (1)  the  aircraft  identification,  (2)  an  abbreviated 
version  of  the  content  of  the  uplinked  message,  and  (3)  and  an  indication  of  the 
current  status  of  the  transaction.  For  example: 

"UAL172  123.125  SNT"  would  indicate  that  the  controller  had  uplinked  a 
message  to  switch  radio  frequencies  to  UAL  172  and  that  the  message  is  in  the 
sent  status. 
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-  Status  List  Abbreviations  of  Transaction  Status 

The  third  field  of  a  status  line  presents  the  following  abbreviations  to  indicate  the 

current  status  of  the  transaction: 

“SNT”  -  Sent:  A  controller  input  or  system  event  has  initiated  the  uplink 

“HLD”  -  Held:  A  transfer  of  communication  message  containing  the  radio 

frequency  of  a  new  airspace  sector,  which  the  aircraft  will  enter,  has 
been  prepared  and  is  ready  for  uplink  when  the  sending  controller 
makes  an  appropriate  input. 

“ROG”  -  Roger 

“AFF”  -  Affirmative 

“WIL”  -  Wilco:  The  system  has  received  a  downlink  from  the  flight  deck 

indicating  that  the  pilot  has  received  the  message  /  agrees  with  /  or  will 
comply  with  the  uplinked  message. 

“NEG”  -  Negative 

“UNA”  -  Unable:  The  system  has  received  a  downlink  from  the  flight  deck 

indicating  that  the  pilot  has  received  the  uplinked  message,  but  does 
not  agree  with  /  is  unable  to  comply. 

“SBY”  -  Standby:  The  system  has  received  a  downlink  from  the  flight  deck 
indicating  that  that  the  pilot  has  received  the  uplinked  message  and 
will  subsequently  reply  with  a  positive  or  negative  response. 

“TIM”  -  Time  Out:  A  timer  initiated  when  the  uplinked  message  was  sent  has 
expired.  This  is  an  adaptable  time  parameter  nominally  set  at  40 
seconds.  The  time  out  status  is  an  indication  to  the  controller  of  an 
unusually  lengthy  delay  for  receipt  of  a  response  from  the  aircraft. 

The  transaction  remains  open,  and  a  subsequent  response  will  be 
accepted  by  the  system. 

“FAI”  -  Failed:  Indicates  that  the  Data  Link  session  with  the  intended 
receiving  aircraft  has  been  aborted.  The  transaction  is  closed. 

“ERR”  -  Error:  Indicates  that  an  application  error  has  occurred  in  attempting 
to  send  the  message.  If  the  data  field  of  the  status  list  entry  indicates 
“local  error”  the  message  has  not  been  received  by  the  pilot.  If  any 
other  message  appears  in  the  data  field,  the  message  may,  or  may  not, 
have  been  received  by  the  pilot.  The  ERR  status  closes  the  transaction 
and  prevents  a  pilot  response. 
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All  states  that  close  a  transaction  with  a  positive  response  (ROG,  WIL,  AFF)  will 
delete  the  relevant  line  on  the  status  list  after  an  adjustable  time  parameter 
(nominally  6  seconds)  has  expired.  Messages  in  any  other  transaction  state 
must  be  manually  deleted  using  inputs  described  in  succeeding  sections  of  this 
booklet. 

-  Full  Data  Block  Indications  for  CPDLC  I  Services  and  Status 

FDB  indicators  are  correlated  with  the  status  list  indicators,  but  vary  depending 
upon  the  service  involved.  They  are  described  in  detail  under  succeeding 
sections  devoted  to  each  service. 

-  Inputs  to  Move  the  Status  List 

The  status  list  can  be  moved  to  any  position  on  the  situation  display  by  pressing 
PVD  “L”,  slewing  to  the  desired  position,  and  pressing  the  trackball  ENTER  key. 

-  Inputs  to  Suppress  or  Retrieve  the  Status  List 

The  status  list  can  be  suppressed  by  typing  DS  F9“ OFF”  or  “SL  OFF”.  The  list  is 
retrieved  to  the  situation  display  by  typing  DS  F9  ”ON”  or  “SL  ON.”  These 
entries  cannot  be  made  from  the  D  position. 

-  Selecting  Message  Types  for  Display  in  the  Status  List 

The  status  list  will  display  information  on  all  four  types  of  messages  included  in 
CPDLC  I.  However,  the  Radar  controller  can  selectively  suppress  status  list 
content  by  message  category.  The  following  table  presents  the  commands  used 
to  selectively  suppress  and  retrieve  each  message  type. 


Category  Key 

Command 

Two-letter 

Command 

Transfer  of 

DSF8“ TC  OFF”  or 

“SV  TC  OFF”  or 

Communication 

“TC  ON” 

“SVTC  ON” 

Menu 

DS  F8  “MT  OFF”  or 

“SV  MT  OFF”  or 

Text 

“MT  ON” 

“SV  MT  ON” 

DSF8  “AS  OFF”  or 

“SV  AS  OFF”  or 

“AS  ON” 

“SVAS  ON” 

All  Message 

DSF8  “OFF”  or 

“SV  OFF”  or 

Types 

“ON” 

“SV  ON” 
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It  is  also  possible  to  display  or  suppress  multiple  message  types  in  a  single 
command  (e.g.,  DS  F8  “TC  MT  OFF”) 

Note  that  any  transaction  that  results  in  a  negative  response  or  a  TIM  will  be 
automatically  forced  to  appear  in  the  status  list  even  if  that  message  type  is 
suppressed. 

-  Selecting  Message  States  for  Display  in  the  Status  List 

The  Radar  controller  also  can  determine  the  messages  that  will  appear  in  the 
status  list  by  their  respective  states.  The  following  table  presents  the  commands 
used  to  selectively  suppress  and  retrieve  the  display  of  messages  in  five  states. 
Messages  with  any  other  status  cannot  be  suppressed. 


Category  Key 

Command 

Two-letter 

Command 

SENT 

DSF10“Sm  OFF”  or 
“SNT  ON” 

“SZ  SNT  OFF”  or 
“SZ  SNT  ON” 

ROGER 

DS  F10“ROG  OFF”  or 
“ROG  ON” 

“SZ  ROG  OFF”  or 
“SZ  ROG  ON” 

WILCO 

DS  FI 0  “WIL  OFF”  or 
"WIL  ON” 

“SZ  WIL  OFF”  or 
“SZ  WIL  ON” 

AFFIRMATIVE 

DS  FI 0  “AFF  OFF”  or 
“AFF  ON” 

“SZ  AFF  OFF”  or 
“SZAFF  ON” 
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Full  Data  Block  and  Status  List  Evaluation 


Questions: 

Do  the  Full  Data  Block  symbols  provide  unambiguous  information  regarding 
Data  Link  equipage/active  session  and  eligibility? 


Are  the  transaction  status  abbreviations  used  in  the  status  list  sufficiently  clear 
and  easy  to  understand? 


Are  the  “abnormal”  status  indications  (NEG,  UNA,  FAI,  ERR,  TIM)  sufficiently 
obvious  to  alert  the  controller  and  prompt  any  needed  action? 


Does  the  design  provide  an  adequate  capability  to  control  (filter)  the  contents  of 
the  status  list  (i.e.,  by  message  type  and  status)? 


When  a  D  position  controller  is  involved  in  sending  Data  Link  messages,  will  the 
status  list  displayed  on  the  R-side  situation  display  be  adequate  for  monitoring 
Data  Link  transactions? 
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Overall  Rating  of  Full  Data  Block  and  Status  List  Displays/Inputs: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  DESIRABLE  OR  NEEDED. 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  NEEDED  BUT  THE  FOLLOWING 
MODIFICATIONS  OR  IMPROVEMENTS  WOULD  BE 
DESIRABLE: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  UNACCEPTABLE 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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PartHI 


Transfer  of  Communication  (TOC) 

-  Function 

The  Data  Link  transfer  of  communication  message  is  automatically  prepared 
when  the  receiving  controller  accepts  a  sector  handoff  for  an  equipped  aircraft. 
The  sending  controller  has  the  option  to  send  the  new  frequency  automatically 
when  the  handoff  is  accepted,  or  to  send  the  message  manually  at  a  later  time. 

-  Inputs  to  Set  the  Transfer  of  Communication  Mode 

Transfer  of  communication  can  be  set  to  the  automatic  mode  by  typing 
DS  FI  “AUTO”  or  “AT  AUTO”.  The  manual  mode  is  selected  by  typing  DS  FI 
“MAN”  or  “AT  MAN”.  Note  that,  as  the  default  function,  FI  may  be  omitted  from 
the  command  sequence. 

The  selected  mode  for  TOC  is  shown  in  a  banner  on  the  situation  display. 

-  Automatic  and  Manual  Send  Inputs 

When  in  the  automatic  mode,  the  transfer  of  communication  message  will  uplink 
the  default  frequency  for  the  receiving  sector  with  no  additional  action  by  the 
sending  controller  when  the  receiving  sector  accepts  the  handoff. 

When  in  the  manual  mode,  acceptance  of  the  handoff  will  store  the  message  for 
later  transmission.  The  message  will  appear  in  the  status  list  in  the  “HLD” 
status.  The  controller  can  send  the  message  by  a  trackball  slew/ENTER  to  the 
“dot”  preceding  the  appropriate  line  in  the  status  list  or  by  pressing  the  TC  UP 
key  followed  by  the  FLID,  or  by  typing  “UH”  followed  by  the  FLID. 

-  Changing  the  Default  Frequency 

Frequencies  other  than  the  primary  default  frequency  for  the  receiving  sector 
can  be  sent  when  using  CPDLC  for  the  transfer  of  communication.  When 
making  the  entries  to  handoff  the  aircraft,  typing  “U”  after  the  sector  number 
will  substitute  a  predefined  alternate  frequency 

(e.g.,  “22  U  TWA254”).  Typing  a  numeric  radio  frequency  value  in  the  same 
position  will  send  that  frequency,  if  adapted,  for  the  facility. 
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-  Status  List  and  Full  Data  Block  Displays  on  Transfer  of  Communication 

The  status  list  entry  for  a  transfer  of  communication  transaction  presents  the 
AID,  the  uplinked  frequency,  and  the  current  transaction  status  message.  When 
in  a  manual  mode,  the  "HLD"  status  message  is  displayed  until  the  controller 
completes  the  slew  action  or  keyboard  to  send  the  message.  In  the  automatic 
mode,  the  status  line  appears  in  the  "SNT"  state  immediately  after  acceptance  of 
the  handoff. 

In  either  mode  of  operation,  when  the  transfer  of  communication  message  is 
sent,  a  “pound”  symbol  (#)  replaces  the  Data  Link  equipage/eligibility  indicator 
in  the  first  position  of  the  first  line  of  the  Full  Data  Block.  This  symbol  will 
appear  at  all  sectors  displaying  the  aircraft’s  full  data  block.  When  the  wilco  is 
received  from  the  flight  deck,  the  pound  symbol  is  replaced  by  the  hourglass  in 
the  receiving  sector  and  by  the  open  diamond  in  all  other  sectors. 

In  an  interfacility  transfer  of  communication,  the  receiving  sector  will  display  the 
hourglass  and  all  Data  Link  eligibility  symbology  will  be  removed  from  sectors  in 
the  sending  facility. 

-  Unable  and  Time  Out  Displays  for  Transfer  of  Communication 
and  Controller  Responses. 

If  the  flight  deck  responds  to  a  transfer  of  communication  message  with  an 
unable,  "UNA"  is  displayed  in  the  status  field  of  the  status  list.  If  the  flight  deck 
fails  to  downlink  a  response  within  40  seconds  (adaptable),  "TIM"  is  displayed  in 
the  status  field. 

The  unable  conditions  also  will  cause  the  pound  symbol  in  the  first  position  of 
the  first  line  of  the  sending  controller's  Full  Data  Block  to  revert  to  the  hourglass 
symbol  indicating  that  Data  Link  eligibility  remains  at  the  sending  sector.  All 
other  sectors  will  display  the  open  diamond. 

-  Deleting  Transfer  of  Communication  Transactions 

The  controller  can  close  the  transaction  and  delete  “HLD”,  "UNA”,  “ERR”,  or 
“FAI”  indicators  by  typing  DL  F6“ TC”  and  the  FLID  or  “DE  TC”  and  the  FLID.  If 
the  controller  chooses  to  delete  a  transaction  in  the  “SNT”,  “SBY”  or  “TIM” 
states  “/OK”  must  be  included  in  the  command  sequence  prior  to  “TC”  (e.g.,  DL 
F3“ /OK  TC  USA219”). 

A  transaction  can  also  be  deleted  by  eliminating  “TC”  in  the  command  and  using 
the  trackball  to  select  the  dot  preceding  the  appropriate  line  in  the  status  list. 
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-  Sending  an  Automatic  Transfer  of  Communication  When  in  Manual 
Mode 

While  working  in  the  manual  mode,  the  controller  can  selectively  choose  to  send 
the  message  automatically  to  an  individual  aircraft  by  adding  a  single  keystroke 
to  the  normal  sequence  used  to  offer  a  handoff. 

The  transfer  of  communication  message  will  be  sent  automatically  upon  handoff 
acceptance  if  the  controller  offers  the  handoff  by  typing  the  two-digit  receiving 
sector  number,  “  S”,  and  the  FLID  (e.g.,  “22  S  USA435”).  Alternate  frequency 
options  may  be  included  in  the  command.  Only  one  aircraft  may  be  designated 
in  the  message.  Adding  the  “  S”  to  a  single  handoff  command  will  not  affect 
other  subsequent  aircraft  handoffs,  and  the  selected  mode  will  remain  manual. 

-  Holding  a  Transfer  of  Communication  When  in  Automatic 

While  working  in  the  automatic  mode,  the  controller  can  selectively  choose  to 
hold  the  message  for  an  individual  aircraft  by  adding  a  single  keystroke  to  the 
normal  sequence  used  to  offer  a  handoff. 

The  transfer  of  communication  message  will  be  put  into  the  held  status  upon 
handoff  acceptance  if  the  controller  offers  the  handoff  by  typing  the  two-digit 
receiving  sector  number,  “  I”,  and  the  FLID  (e.g.,  “22  I  USA435”).  Alternate 
frequency  options  may  be  included  in  the  command.  Only  one  aircraft  may  be 
designated  in  the  message.  Adding  the  “I”  to  a  single  handoff  command  will  not 
affect  other  subsequent  aircraft  handoffs,  and  the  selected  mode  will  remain 
automatic. 

-  Acquiring  Data  Link  Eligibility  Without  a  Handoff 

If  a  controller  has  track  control  for  an  aircraft,  Data  Link  eligibility  can  be 
acquired  from  another  sector  in  the  absence  of  a  completed  handoff  by  typing 
DL  F3  or  “AL”,  followed  by  the  FLID.  This  action  does  not  uplink  the  acquiring 
sector’s  radio  frequency  to  the  aircraft.  (NOTE:  two-letter  command  in  Test  Bed 
is  “SX”  -  change  to  “AL”  is  pending) 

Track  control  and  Data  Link  eligibility  can  be  acquired  from  another  sector  in 
the  absence  of  a  handoff  with  a  single  input  by  typing  “/OK  D”  and  the  FLID. 

-  Sending  a  Radio  Frequency  to  an  Aircraft  Without  a  Handoff 

A  controller  who  has  acquired  Data  Link  eligibility  in  the  absence  of  a  handoff 
can  send  his/her  sector’s  radio  frequency  to  the  aircraft  by  typing  DL  F2  or  “UF”, 
followed  by  the  FLID. 
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Frequencies  other  than  the  primary  default  frequency  for  the  sector  can  be 
substituted.  Typing  “UF  U”  or  DL  F2“ U”,  followed  by  the  FLID  will  substitute  a 
predefined  alternate  frequency.  Typing  a  numeric  radio  frequency  value,  rather 
than  “U”,  will  send  that  frequency  if  adapted  for  the  facility. 

When  a  frequency  is  sent  in  this  manner,  the  message  will  instruct  the  pilot  to 
“monitor”  the  new  frequency.  If  “C”  is  inserted,  the  message  will  instruct  the 
pilot  to  “contact”  the  controller  on  the  new  frequency 
(e.g.,  “UF  C  NWA899”). 

-  Initiating  a  Handoff  Without  Preparing  a  Transfer  of  Communication 
Message 

An  aircraft  with  an  ongoing  Data  Link  session  can  be  handed  off  without 
preparing  or  sending  a  transfer  of  communication  message  by  typing  the 
receiving  sector’s  number,  “O”  and  the  FLID  (e.g.,  “22  O  USA219”). 

-  Forwarding  Data  Link  Eligibility  when  CPDLC  Transfer  of  Communication  is 
Off 

A  controller  who  has  turned  Data  Link  off  at  his  sector,  or  who  elects  not  to  use 
Data  Link  to  accomplish  the  transfer  of  communications,  must  forward  eligibility 
to  the  next  sector.  After  handing  off  an  aircraft  and  instructing  the  aircrew  to 
contact  the  next  sector  via  voice  radio,  the  controller  will  forward  eligibility  to 
the  sector  with  track  control  by  typing  DL  FI  or  “RL”,  followed  by  the  FLID. 
(NOTE:  two-letter  command  in  Test  Bed  is  “RE”  --  change  to  “RL”  is  pending) 
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Transfer  of  Communication 


Evaluation 

Questions: 

1.  Are  the  available  input  options  for  sending  a  “held”  transfer  of 
communication  message  adequate  for  the  R  controller?  D  controller? 


2.  Are  the  Full  Data  Block  indicators  along  with  the  status  list  adequate  for 
monitoring  an  ongoing  transfer  of  communication  transaction? 


3.  Are  the  inputs  for  temporarily  changing  the  transfer  of  communication  mode 
(auto/manual)  for  a  single  aircraft  acceptable? 


4.  Are  the  inputs  used  to  “steal”  Data  Link  eligibility  acceptable? 


5.  Are  the  inputs  used  to  send  a  voice  radio  frequency  in  the  absence  of  a 
handoff  acceptable? 


6.  Will  the  options  to  substitute  an  alternate  frequency  in  the  handoff  message 
(“U”,  typed  frequency)  and  to  inhibit  the  preparation  of  a  TOC  message  (“O”) 
adequately  support  the  controller’s  operational  requirements? 
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7.  Are  the  inputs  required  for  releasing  eligibility  when  a  controller  has 
Data  Link  “off’  at  the  sector  acceptable  ? 


Overall  Rating  of  Transfer  of  Communication  Displavs/Inputs: 

_  THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 

NO  CHANGES  ARE  DESIRABLE  OR  NEEDED. 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  NEEDED  BUJ  THE  FOLLOWING 
MODIFICATIONS  OR  IMPROVEMENTS  WOULD  BE 
DESIRABLE: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  UNACCEPTABLE— 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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Part  IV 


Initial  Contact  (IC) 

-  Function 

This  service  substitutes  the  initial  radio  call  from  the  flight  deck  after  a  transfer 
of  communication  with  a  downlink  report  of  assigned  altitude.  Under  normal 
conditions,  the  initial  contact  procedure  is  automatic  and  transparent,  and 
requires  no  controller  interaction. 

-  Initial  Contact  Procedure 

An  assigned  altitude  request  message  is  automatically  appended  to  the  radio 
frequency  assignment  message  that  is  uplinked  during  transfer  of 
communication.  The  flight  deck  responds  to  the  transfer  of  communication 
uplink  by  downlinking  a  wilco  along  with  a  report  of  assigned  altitude  to  the 
receiving  controller. 

Receipt  of  the  wilco  response  transfers  Data  Link  eligibility  to  the  receiving 
sector.  In  addition,  the  reported  assigned  altitude  is  automatically  checked 
against  the  aircraft's  assigned  altitude,  interim  altitude,  or  adapted  altitude 
recorded  in  the  NAS  database.  If  the  aircraft's  reported  downlinked  assigned 
altitude  matches  the  database  value,  nothing  is  displayed  at  the  sending  or 
receiving  sectors,  and  no  additional  controller  action  is  required. 

Note  that  the  transfer  of  communication  message  will  normally  instruct  the  pilot 
to  “monitor”  the  new  frequency.  If  the  new  sector  is  not  equipped  for  Data  Link, 
it  will  instruct  the  pilot  to  “contact”  the  controller  at  the  new  frequency  and  no 
altitude  request  will  be  sent. 

-  Discrepancy  Between  Reported  and  Assigned  Altitudes 

If  the  reported  assigned  altitude  fails  to  match  the  assigned  or  interim  altitude 
contained  in  the  NAS  database,  the  downlinked  value  followed  by  “I”  will  appear 
in  the  first  four  positions  of  the  second  line  of  the  Full  Data  Block.  This  will 
timeshare  every  1.5  seconds  with  the  database  value  followed  by  the  altitude 
conformance  indicator.  If  the  Mode  C  altitude  had  been  displayed  in  this  field 
when  the  timesharing  began,  the  Mode  C  altitude  will  be  shifted  to  the  right  of 
the  second  line  to  make  it  continuously  viewable. 

In  addition  to  the  FDB  display,  a  status  list  entry  will  be  created  displaying  the 
AID,  the  NAS  data  base  altitude,  and  the  downlinked  altitude.  The  downlinked 


altitude  will  be  right  justified  in  the  data  field  of  the  status  list.  The  status  field 
will  show  “/HC” 

(e.g.,  TWA515  240  340/IIC”). 

The  Data  Link  eligible  receiving  controller  with  track  control  can  resolve  the 
mismatch  by  contacting  the  flight  deck  via  voice  radio.  The  error  displays  may 
be  cleared  by  deleting  the  IC  status  list  entry  (DL  F6“ IC“  and  the  FLID  or  “DE 
IC”  and  the  FLID). 

Initial  Contact 

Evaluation 

Questions: 

1.  Are  the  timeshared  FDB  display  and  the  status  list  indicator  sufficient  to  alert 
the  controller  of  an  initial  contact  downlink  of  an  altitude  that  fails  to  match  the 
NAS  database? 


2.  Are  the  options  for  deleting  an  IC  mismatch  acceptable? 
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Overall  Rating  of  Initial  Contact  Displays/Inputs: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  DESIRABLE  OR  NEEDED. 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  NEEDED  BUT  THE  FOLLOWING 
MODIFICATIONS  OR  IMPROVEMENTS  WOULD  BE 
DESIRABLE: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  UNACCEPTABLE— 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 


B-21 


Part  V 


Menu  Text 

-  Function 

The  Menu  Text  function  permits  the  controller  to  uplink  nonsafety  critical 
messages  by  selecting  them  from  a  predefined  menu  list.  Menus  can  be  tailored 
to  meet  the  specific  requirements  of  individual  airspace  sectors. 

-  Menu  Format 

The  menu  is  a  Host  situation  display  tabular  list  identified  by  "ML”  in  the  header 
area  of  the  list.  Each  line  of  the  menu  contains  one  message  preceded  by  an 
identifying  menu  referent  used  to  select  the  message.  The  menu  referent  must 
begin  with  an  alphabetic  character.  Up  to  10  messages  can  be  displayed  in  the 
menu  list.  A  sample  menu  is  shown  below: 

.A  WRI ILS  OUT RWY 6/24 

.  B  BAD  WEATHER  WARN 

.  MIC  CHECK  STUCK  MIC 

.  CALL  CALL  COMPANY 

-  Inputs  to  Send  a  Menu  Text  Message 

To  send  a  menu  text  message,  press  the  MT  C/P  key  (or  type  “UM”),  the  menu 
item  referent,  and  the  FLID  (e.g.,  MT  UP“A  USA456”).  The  menu  item  referent 
can  be  typed  or  selected  by  a  trackball  slew  to  the  dot  preceding  the  message  in 
the  list. 

The  message  can  be  sent  to  all  aircraft  that  are  Data  Link  eligible  for  the  sector 
by  substituting  “  *ALL  ”  for  the  FLID. 

-  Full  Data  Block  and  Status  List  Displays  on  Menu  Text  Uplink 

When  a  menu  text  message  is  uplinked,  an  up-arrow  ( Q  )  symbol  replaces  the 
hourglass  in  the  first  position  of  the  first  line  of  the  Full  Data  Block  at  all 
positions  displaying  the  Full  Data  Block.  The  up-arrow  is  removed  when  the 
message  receives  the  appropriate  positive  or  negative  response  from  the  flight 
deck  or  when  it  is  deleted  from  the  status  list. 

For  all  messages  sent  from  the  menu,  the  status  list  will  display  the  AID  followed 
by  the  menu  item  referent,  and  the  current  status  of  the  transaction  (e.g.,  "AA231 
CALL  SNT").  The  status  list  line  is  deleted  when  the  appropriate  positive  or 
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negative  response  from  the  flight  deck  is  received,  or  when  it  is  deleted  from  the 
status  list. 

When  a  message  is  sent  to  all  aircraft,  a  single  line  is  created  in  the  status  list 
with  “ALL”  appearing  the  FLID  field.  The  status  line  is  deleted  when  all  of  the 
aircraft  respond  with  the  appropriate  positive  response.  A  separate  line  is 
created  in  the  status  list  for  each  negative  aircraft  response  to  an  all  message,  or 
if  a  transmission  error  occurs  (“ERR”,  “FAI”). 

-  Deleting  Menu  Text  Transactions 

The  controller  can  close  the  transaction  and  delete  "UNA", “ERR”,  “FAI”,  or 
“NEG”  indicators  by  typing  DL  “MT”  and  the  FLID  or  “DE  MT”  and  the  FLID. 
If  the  controller  chooses  to  delete  a  transaction  in  the  “SND”,  “SBY”  or  “TIM” 
states,  “/OK”  must  be  included  in  the  command  sequence  prior  to  “MT”  (e.g.,  DL 
F6U MT  /OK  USA219”).  The  transaction  can  also  be  deleted  by  eliminating  the 
“MT”  and  FLID  in  the  command  and  using  the  trackball  to  select  the  dot 
preceding  the  appropriate  line  in  the  status  list.  If  the  trackball  is  not  used  for 
this  command,  all  MT  transactions  for  the  aircraft  that  are  displayed  in  the  status 
list  will  be  deleted. 

-  Controlling  Menu  Text  List  Content 

A  menu  build  function  will  be  used  by  supervisory  personnel  to  create  sector- 
tailored  menus.  However,  the  controller  will  have  the  capability  to  determine 
whether  the  menu  list  will  be  displayed,  and  to  selectively  display  or  suppress 
individual  items.  Messages  continue  to  be  available  for  uplink  when  suppressed 
from  the  display. 

The  menu  list  can  be  suppressed  by  typing  DS F3“ OFF”  (or  “MT  OFF”).  The  list 
is  retrieved  to  the  situation  display  by  typing  DS F3” ON”  or  (“MT  ON”).  These 
entries  cannot  be  made  from  the  D  position. 

Suppression  of  the  individual  messages  in  the  menu  is  accomplished  by  typing 
DS  F4 ,  the  menu  item  referent,  and  “OFF”  or  “MS”,  the  menu  referent,  and 
“OFF”.  A  message  can  be  retrieved  by  substituting  “ON”  in  the  command 
sequence. 

Up  to  five  messages  can  be  suppressed  or  retrieved  in  a  single  command  by 
separating  the  menu  referents  with  spaces. 

It  should  be  noted  that  sectors  may  be  assigned  two  types  of  menu  messages. 
Permanent  messages  intended  for  routine  use  on  a  daily  basis  may  be 
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suppressed  from  the  list.  The  system  will  not  permit  suppression  of  temporary 
messages  created  for  nonroutine  special  situations. 

-  Inputs  to  Move  the  Menu 

The  menu  text  list  can  be  moved  to  any  position  on  the  situation  display  by 
pressing  PVD  “A”,  slewing  to  the  desired  position,  and  pressing  the  trackball 
ENTER  key. 

Menu  Text 

Evaluation 

Questions: 

1.  Are  the  available  input  options  for  sending  a  menu  text  message  adequate  for 
the  R  controller?  D  controller? 


2.  Are  the  FDB  indicators  along  with  the  status  list  adequate  for  monitoring  an 
ongoing  menu  text  transaction? 


3.  Are  the  options  for  suppressing/retrieving  items  in  the  menu  text  list 
acceptable? 
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Overall  Rating  of  Menu  Text  Displavs/Inputs: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  DESIRABLE  OR  NEEDED. 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  NEEDED  BUT  THE  FOLLOWING 
MODIFICATIONS  OR  IMPROVEMENTS  WOULD  BE 
DESIRABLE: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  UNACCEPTABLE 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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Part  VI 


Altimeter  Setting  (AS) 

-  Function 

This  Data  Link  message  uplinks  an  altimeter  setting  to  the  flight  deck. 

Normally,  the  uplink  will  be  accomplished  automatically  in  accordance  with 
procedures  and  directives.  An  altimeter  setting  can  also  be  manually  uplinked 
by  the  controller. 

-  Manual  Uplink  of  Altimeter  Setting 

An  altimeter  setting  can  be  manually  uplinked  by  pressing  CRD,  typing  the 
designator  for  the  station  providing  the  local  altimeter  setting,  “S”  and  the  FLID. 

-  Full  Data  Block  and  Status  List  Displays  for  Altimeter  Setting  Messages 

When  an  altimeter  setting  message  is  uplinked  either  automatically  or  manually, 
an  up-arrow(  QDQ)  symbol  replaces  the  hourglass  in  the  first  position  of  the  first 
line  of  the  Full  Data  Block  at  all  positions  displaying  the  FDB.  The  up-arrow  is 
removed  when  the  message  receives  a  “ROG”  or  “UNA”,  or  is  deleted  from  the 
status  list. 

For  all  altimeter  messages,  the  status  list  will  display  the  AID  followed  by  the 
station  designator  and  the  altimeter  setting,  and  the  current  status  of  the 
transaction  (e.g.,  “AAL231  DCA2997  SNT”).  The  status  list  line  is  deleted 
when  a  “ROG”  is  received.  Messages  in  any  other  transaction  state  must  be 
manually  deleted. 

-  Deleting  Altimeter  Setting  Transactions 

The  controller  can  close  the  transaction  and  delete  “UNA”  or  “ERR”  indicators 
by  typing  DL  F6“ AS”  and  the  FLID  or  “DE  AS”  and  the  FLID.  If  the  controller 
chooses  to  delete  a  transaction  in  the  “SND”,  “SBY”  or  “TIM”  state  “/OK”  must 
be  included  in  the  command  sequence  prior  to  “AS”  (e.g.,  DL  F6 “/OK  AS 
USA219”).  The  transaction  can  also  be  deleted  by  eliminating  the  “AS”  and  FLID 
in  the  command  and  using  the  trackball  to  select  the  line  in  the  status  list.  If  the 
trackball  is  not  used  for  this  command,  all  AS  transactions  for  the  aircraft  that 
are  displayed  in  the  status  list  will  be  deleted. 

Altimeter  Setting 
Evaluation 
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Questions: 

Are  the  inputs  for  sending  an  altimeter  setting  message  adequate  for  the  R 
controller?  D  controller? 


Are  the  Full  Data  Block  indicators  along  with  the  status  list  adequate  for 
monitoring  an  ongoing  altimeter  setting  transaction? 


Overall  Rating  of  Altimeter  Setting  Displays/Inputs: 

THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  DESIRABLE  OR  NEEDED. 


THE  DESIGN  AS  DESCRIBED  HERE  IS  ACCEPTABLE  - 
NO  CHANGES  ARE  NEEDED  BUT  THE  FOLLOWING 
MODIFICATIONS  OR  IMPROVEMENTS  WOULD  BE 
DESIRABLE: 


THE  DESIGN  AS  DESCRIBED  HERE  IS  UNACCEPTABLE— 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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GENERAL  QUESTIONS: 


1.  Are  the  inputs  and  displays  for  accomplishing  functions  under  the  Data 

Link  Settings  menu  acceptable  for  managing  the  contents  of  the  Menu  Text 
List?  Status  List? 


2.  Do  you  feel  that  the  Data  Link  turn  around  times  (elapsed  time  from 

sending  a  message  to  receiving  a  pilot  response)  that  you  experienced  in 
the  simulations  are  short  enough  to  enable  effective  use  of  CPDLC I  by 
controllers  in  the  field? 


3.  Earlier  CPDLC  studies  indicated  that  controllers  would  prefer  the  the  Full 
Data  Block  indicators  for  equipage  and  eligibility  be  changed  from  the  open 
diamond  and  “hourglass”  to  an  open  diamond  (active  session  but  not 
eligible)  and  a  filled  diamond  (active  session  and  eligible).  Please  indicate 
your  preferences  below  by  placing  a  check  mark  in  the  appropriate  column 
for  each  symbol  set: 


Best 

Option 

Acceptable 

Option 

Unacceptable 

Option 

Open  Diamond  / 
Hourglass 

Open  Diamond  / 
Filled  Diamond 

4.  The  current  Full  Data  Block  indication  for  an  ongoing  transfer  of 

communications  is  the  pound  symbol.  A  currently  available  alternative 
is  a  lightning  bolt.  Please  indicate  your  preferences  below  by  placing  a 
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check  mark  in  the  appropriate  column  for  each  symbol  set: 


Best 

Option 

Acceptable 

Option 

Unacceptable  ! 

Option 

Pound 

Symbol 

Lightning 

Bolt 

5.  In  future  builds,  would  a  “repeater”  of  the  Status  List  at  the  DSR 
D  position  display  be  desirable? 


6.  In  future  builds,  do  you  feel  that  it  will  be  useful  to  take  advantage  of 
the  DSR’s  color  capability  to  emphasize  important  information  and 
warnings  (e.g.,  color  coding  of  unable  responses,  failures,  and  timeouts 
in  the  Status  List)? 


7.  Do  you  feel  that  the  training  and  DYSIM  exercises  on  DSR  and  Data 
Link  that  you  received  for  this  study  provided  you  with  an  adequate 
basis  for  evaluating  CPDLC  I? 


8.  Based  on  your  experience  in  learning  CPDLC  I  for  this  study,  do  you 
feel  that  a  training  program  consisting  of  a  1-hour  overview  lecture, 

4  hours  of  Computer-Based  Instruction  (CBI),  a  2-hour  procedure 
lecture,  and  6  hours  of  DYSIM  exercises  will  be  adequate  for  training 
controllers  in  the  field? 
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9.  In  the  current  design,  the  D-Side  keyboard  does  not  include  the  DL  and 
DSkeys.  Where  accessible  to  the  D-Side,  the  functionality  provided 
under  these  keys  must  be  accessed  using  two-letter  commands.  In  a 
future  build,  do  you  feel  that  it  would  be  useful  to  provide  these  keys  on 
the  D-Side  keyboard  or  in  a  category  “pick”  area  on  the  D-CRD  ? 
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